fix(cast): skip HyperEVM system transactions on replay - #16451

HyperCore credits native HYPE to HyperEVM accounts through transactions sent by 0x2222222222222222222222222222222222222222. They are legacy envelopes with gasPrice = 0, an r/s of 1, and a receipt gasUsed of 0. That sender was not in is_known_system_sender, so block replay executed them like regular transactions and aborted with transaction validation error: gas price is less than basefee — which takes down cast run for every transaction in the block, not just the credit itself. Sparse sampling of recent HyperEVM blocks put these in roughly 1% of them.

Adding the address to the known system senders makes both cast run and the fork backend skip them, the same way Arbitrum, Optimism, Monad and MegaETH system transactions are already skipped. Skipping is also the right state: the credit lands in the block being replayed, and the fork DB resolves balances at the parent, so the pre-credit balance is what the following transactions should see.

Before, every transaction in HyperEVM block 44427759 failed the base fee check. After, all four user transactions replay to the exact receipt gas (134377, 134365, 39302, 119578), and targeting the credit itself reports is a system transaction instead of an EVM error. Transactions in blocks without a credit are unaffected.

Found while looking into how well the suite reproduces HyperEVM execution. With this and an archive RPC, cast run matched the receipts on 22 of 24 sampled transactions; the two that still differ call the node-native HyperCore read precompiles at 0x0800-0x0810, which is a separate problem and relates to #7262.

Related: #10863, #10827, #10820.

This PR was written by Claude Code: the investigation that found the bug, the change, and this description. Verified against live HyperEVM blocks as described above.